Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9608 / 000015_owner-urn-ietf _Fri Aug 16 15:49:53 1996.msg < prev next >

Wrap

Internet Message Format | 1997-02-19 | 33KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19801 for urn-ietf-out; Fri, 16 Aug 1996 15:49:53 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19789 for <urn-ietf@services.bunyip.com>; Fri, 16 Aug 1996 15:49:45 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26560 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 15:49:35 -0400 Received: from magenta.acl.lanl.gov (magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA22099 for <urn-ietf@bunyip.com>; Fri, 16 Aug 1996 13:49:34 -0600 (MDT) From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov> Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.6.9/8.6.4) id NAA07281 for urn-ietf@bunyip.com; Fri, 16 Aug 1996 13:49:33 -0600 Date: Fri, 16 Aug 1996 13:49:33 -0600 Message-Id: <199608161949.NAA07281@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] revision 1 of the NAPTR draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" <rdaniel@acl.lanl.gov> Errors-To: owner-urn-ietf@bunyip.com INTERNET DRAFT Ron Daniel draft-daniel-naptr-01.txt Los Alamos National Laboratory Michael Mealling Georgia Institute of Technology 16 Aug, 1996 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 16 Feb., 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a replacement for URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. However, their brittle nature over time has been recognized for several years. The Uniform Resource Identifer working group proposed the development of Uniform Resource Names to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] sets forth requirements on URNs. Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independance for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The developers of various URN proposals have held a series of meetings, resulting in a compromise known as the Knoxville framework. The major principle behind the Knoxville framework is that any name assignment hierarchy should be seperate from the resolution hierarchy. This is in marked contrast to the Domain Name System, where the two are identical. Readers are referred to [2] for background on the Knoxville framework for additional information on the context and purpose of this proposal. For the reasons mentioned earlier, we want to be able to resolve URNs and URLs within the same framework. For the short term, DNS is the obvious candidate for the resolution framework, since it is widely deployed and understood. However, it is not appropriate to use DNS to maintain information on a per-resource basis. First of all, DNS was never intended to handle that many records. Second, the limited record size is inappropriate for catalog information. Third, we have the requirement mentioned above about grandfathering of other name systems. Therefore our approach is to use DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to seperate the name assignment and resolution procedures. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Terminology =========== "Must" or "Shall" - Software that does not behave in the mannar that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, replacement, and regexp: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR recors in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver, and will be specified in other documents. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These are discussed in the URN Framework document[2], and their behavior in a particular resolution protocol will be given in the specification for that protocol. * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. * The replacement field is one of two fields used for the rewrite rules. If the rewrite is a simple substitution of a domain name, that name is given in the replacement field. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. * The regexp field is the other field that may be used for rewrite rules. The regexp field is a String containing sed-style substitution expressions. These are applied to the original URN and yield the next domain name to be queried. Note that the client applies all the substitutions and performs all lookups - this is not handled in DNS servers. Note also that there is no reason to provide values in both the replacement and regexp field. Only one should be specified. If a value is specified in both, the replacement name MUST be used and the regexp string MUST be ignored. It is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Example 1 --------- Consider a URN that uses the DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service replacement regexp IN NAPTR 100 10 "s" "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com "" IN NAPTR 100 20 "s" "rcds+N2C" _rcds._udp.isi.dandb.com "" IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.isi.dandb.com "" The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS) could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existant NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. Since our example RR specified the "s" flag, it was terminal. Our next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds._udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). Since a domain administrator knows certain NAPTRs are terminal, (s)he might include the corresponding SRV RRs as additional info. Further, the SRV RRs could include A records as additional info. While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [4]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Records MUST be processed in the order specified by the order field. This allows administrators to say that "all records matching this pattern go to server1, all others go to server2". Records SHOULD be processed in the order specified in the preference field. However, clients may have a preference for particular protocols and resolution services that causes them to ignore the preference field, so resolver administrators cannot count on the preference field always being respected. Example 2 --------- Consider a URI namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: ;; order pref flags service replacement regexp cid.urn.net IN NAPTR 100 10 "" "" . "/.+@([^@]+)/\1/i" We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the regexp returns the string "mordred.gatech.edu". Since the flags field is empty, the lookup is not terminal, and our next probe to DNS is for NAPTR records. The result might look something like: *.gatech.edu IN NAPTR ;; order pref flags service replacement regexp IN NAPTR 100 50 "s" "z39.50+N2L+N2C" _z3950._tcp.gatech.edu "" IN NAPTR 100 50 "s" "rcds+N2C" _rcds._udp.gatech.edu "" IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" _http._tcp.gatech.edu "" Note that a wildcard has been used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. The values of the order and preference fields are equal in all records, so we are free to pick any record. The flags field tells us that this is the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target _z3950._tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Users of regular expressions should note that there is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually recieves the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- As mentioned above, the NAPTR RR can also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service replacement regexp 100 90 "" "" . "/.*\/\/([^\/:]+)/\1/i" This expression returns everything after the first double slash and before the next slash or colon. Backslashes are needed to escape the forward slash since the forward slash character is what seperates the components of the substitution pattern. (Recall from the previous example that in the zone file, this pattern actually needs to be entered as "/.*\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service replacement regexp IN NAPTR 100 100 "s" "http+L2R" _http._tcp.foo.com "" IN NAPTR 100 100 "s" "ftp+L2R" _ftp._tcp.foo.com "" Looking up SRV records for _http._tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104. Domain TTL Class Order Preference Flags Service Replacement Regexp where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting. Flags are single characters from the alphabet [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only two flags, "S" and "A", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The S and A flags are mutually exclusive, and resolution libraries SHOULD signal and error so that bad NAPTRs can be quickly detected. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. Service Specifies the resolution service(s) available down this rewrite path. May also specify the particular protocol that is used to talk with a resolver. If a protocol is specified in the service field, the rewrite will almost certainly be terminal, although the flags field MUST still be considered the authoritative source of information on that subject. The service field may take any of the values below (using the Augmented BNF of RFC 822[5]): service_field = [ [protocol] *("+" rs)] protocol = "RCDS" / "HTTP" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "L2R" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are RCDS (a binary, UDP-based protocol) and HTTP (a textual, TCP-based protocol). More will be allowed later. At this time the allowed service requests are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. L2R - Given a URL, return the resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. Regexp A STRING containing a sed(1)-style substitution expression that is applied to the original URI in order to construct the next name to lookup. For example: "/^.*inet:([^:]+):*/\\1/i" Regular expression replacement. The URN will be searched from the beginning for the pattern "inet:". All characters after that colon, up to but not including the next colon, will form the next domain name to be looked up. The /i flag says that the match will be case-insensitive, so IneT, Inet, INET, ... would all be matched. The new search key would also be normalized to lower case. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Administrators are strongly encouraged to provide SRV records or A records as additional information in terminal NAPTR records. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. Usage ===== Pseudocode for a client routine using NAPTRs is given below: // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field. n_naptrs = number of NAPTR records in response. curr_order = records[j].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a sucessful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - The "urn:" prefix is a matter of religious controversy. Client code should handle the cases when it is and is not present. Similarly, if regular expressions are used in NAPTR records, they should be immune to the presence or absence of "urn:". - A client MUST examine all the RRs in a reply, not just the first. The client MUST process them according to the value of the order field. Once a NAPTR has "matched" a URN, the client MUST NOT consider any NAPTRs with a higer value of order than that of the matching NAPTR, even if it does not know the protocols necessary to talk with the matching resolver. (A match is defined as: 1) The NAPTR provides a replacement domain name 2) The regular expression matches the URN ) - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client should continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necesary to make delegation of portions of the namespace work. - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - Note that SRV RRs impose additional requirements on clients. Acknowledgements: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] draft-gulbrandsen-dns-rr-srvcs-03.txt " A DNS RR for specifying the location of services (DNS SRV)", Arnt Gulbrandsen and Paul Vixie, March 1996. [4] Paul Vixie, personal communication. [5] RFC-822 "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [6] Keith Moore, personal communication. Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Office of Information Technology, Network Services Georgia Institute of Technology Atlanta, GA, USA 30332-0730 voice: (404) 894-1712 fax: (404) 894 9548 michael.mealling@oit.gatech.edu This draft expires 16 Feb., 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 slogan: "Dump Navigator Now!"